Ekibin Ar-Ge verimliliği nasıl artırılır? Ali mühendisleri yapar
Alimeinin Kılavuzu: İşletme uluslararası hale geldikçe, beklenmedik zorluklar birbiri ardına gelir. Ekip, sarışın ve mavi gözlü bir mühendisi, iş desteğini ve zarif kod sürtünmesini, iletişim ve işbirliğini, araştırma ve geliştirme modelini, kültürel atmosferi ve bunlara nasıl adapte olunacağını memnuniyetle karşılar. Yeni değişiklikler mi? Bugün, Aliexpress kıdemli teknik uzmanı Xu Xiaobin'i çözümünü paylaşmaya davet ediyoruz.
arka fon
Yaklaşık 5 yıl önce, 2013'te DevOps rüzgarı patladığında Ali'ye ilk katıldığımda, bir şirket günde düzinelerce yüzlerce kez yayın yapabileceğini iddia etti, bu da geleneksel yazılım şirketleriyle karşılaştırıldığında bu anlamına geliyor. Haftalık yayına göre, iş ihtiyaçlarına cevap verme yetenekleri ikincisini birkaç bloğu aşabilir ve bu boşluk fazla mesai tarafından kapatılamaz. Bugünün AliExpress teknik ekibi birkaç yüz kişi kadar küçüktür ve günde onlarca kez yayın yapmak yaygındır. Bu, temel olarak üç yönden kaynaklanmaktadır:
Bununla birlikte, verimlilik için asla "Yeterince, yeterince hızlı" demeyeceksiniz, özellikle herkesin tüketici olduğu ve tüketicilerin arzularının ortaya çıkmasını bekleyemeyecekleri mevcut tüketim toplumunda. Malları veya hizmetleri anında ona geldi. Dahası, uluslararasılaşmaya devam ederken, yeni faktörler kaçınılmaz olarak orijinal yüksek performansı etkileyecektir.
İletişim bant genişliği zayıflama sorunu
İlk faktör, Ar-Ge ekibinin kendisinin geliştirilmesi ve değişmesidir. Bugünün AliExpress teknik ekibi, halihazırda gerçek anlamda dağıtılmış uluslararası bir ekiptir. Çalışma yeri Hangzhou + Shenzhen + Moskova + Madrid + diğer Avrasya şehirleridir. Yabancı öğrencilerin oranı % 15 olup, bu oranın artmaya devam edeceği, yeni yabancı çalışma yerlerinin de artacağı görülmektedir. Ve böyle bir ekip, aynı kattaki bir grup Çinli'den oluşan bir ekipten esasen farklıdır.
İnsandan insana iletişimi ağ iletişimi ile karşılaştırabiliriz. Ağ iletişiminin bant genişliğine sahip olduğunu biliyoruz. Onlarca K'nin erken çevirmeli İnternet erişiminden, onlarca ila yüzlerce milyonluk mevcut ana ev geniş bantına ve ardından verilere Merkezin dahili LAN'ındaki G seviyesinin büyüklük sırası, bant genişliği ne kadar büyükse, o kadar fazla bilgi iletilebilir (genellikle daha fazla israf). İnsanlar arasındaki iletişimin de bant genişliğine sahip olduğu düşünülebilir. Örneğin, Çinli mühendislerden oluşan, tamamen güvenilir mühendislerden oluşan küçük bir ekip genellikle yemek yer, yürür ve birbirleriyle sohbet eder. Herkes birbirini çok iyi tanır ve iletişim özellikle sorunsuzdur. Bir fikir düşünüyorsanız. Diğer taraf sadece birkaç kelimeyle anlayacaktır. Ancak, dağıtılmış uluslararası bir ekip için, bu iletişim bant genişliği büyük ölçüde zayıflatılmıştır:
- Çince'den İngilizce'ye dönüştürme, bir kez zayıflatma. Çoğu insan için İngilizce anadili değildir ve iletişimin etkinliği doğal olarak azalacaktır.
- Birden fazla zemine tek zemin, bir kez zayıflatma. Telefon, video ve DingTalk yüz yüze iletişim kadar verimli değildir. (Aksi takdirde herkes yüzünü aynı şekilde fırçalamayacaktır)
- Zaman farkı tekrar azalır. Hangzhou ve Moskova arasındaki zaman farkı 5 saattir, bu yüzden temelde Pekin sabahı Moskova'daki sınıf arkadaşlarımızla iletişime geçemiyoruz.
- Kültürel farklılıklar yeniden azalır. Örneğin, duygularımızı geliştirmek için kullanabileceğimiz birçok takım kurma yöntemi vardır. K-şarkıların kralı tavuk yer. Yabancı öğrenciler hiç üşütmeyebilir.
Öyleyse birisi diyebilir, iletişimin maliyeti çok yüksek olduğu için, tüm Çinli mühendisleri tek bir yerde işe almak ne kadar kolay? Bunu yapmak çok basit, ancak bunu yaparsanız, dünyanın her yerinden seçkin yetenekleri nasıl çekebilirsiniz? Dahası, AliExpress kullanıcıları temelde yabancılardır.Bunun arkasındaki yeteneklerinin tamamı Çinli ise, işin pek güvenilir olmadığı anlaşılıyor, değil mi? Google, Microsoft, Amazon, hangisi dünyadaki en iyi yetenekleri toplamıyor?
Bu nedenle, iletişim bant genişliğinin zayıflaması kaçınılmaz olduğundan, yalnızca bu bant genişliğinin kullanımını artırabiliriz. Özellikle, bir şey yaptık veya yapıyoruz:
Kotlin'i kucaklayın
Geliştirme verimliliği ile ilgili olarak, kişisel olarak tüm Java programcılarının Kotlin'e ciddi ve dikkatli bakması gerektiğini düşünüyorum çünkü bu dil çok özlü ve Java ile sorunsuz bir şekilde çalışabilir ve bir üretim ortamında kullanım için tamamen nitelikli.
Özetle ilgili olarak, geçtiğimiz iki gün içinde bir Java kodunu Koltin olarak değiştirdim Okunabilirliği hiç azaltmadan (aslında okunabilirlik geliştirildi), kod satırı uygun şekilde 1/3 oranında azaltıldı.
Ek olarak, HSF hizmeti olarak bir işlev yayınlamak için yakın zamanda Sergey'in Kotlin HSF DSL'ine dayanarak yazdığım bir işlevi paylaşmadan edemiyorum:
Bir Spring Boot uygulamasını başlatmak ve bir HSF hizmeti olarak küçük harfli bir dize işlevi yayınlamak yalnızca 15 satırdan az kod gerektirir.Java'da ne kadar yazmanız gerektiğini karşılaştırabilirsiniz. Dil seviyesi yükseltmesi, çerçeve, ara katman yazılımı ve API tasarımına daha fazla olasılık getiriyor ve bu da daha sözde iskele kodunu kesmemizi, iş kodunu daha akıcı, daha zarif hale getirmemizi ve verimlilik iyileştirmeleri getirmemizi sağlayacak.
Bir programcı olarak, sadece bir dile hakim olmanız çok tehlikelidir, çünkü bu dilin çeşitli tasarımları düşüncenizi sınırlayacaktır. Boş zamanlarımda başka dilleri de okuyacağım, ancak temelde sadece günlük işlerimde Java yazabiliyorum (kabuk da bir dil ise, bazı kabuklar yazdım). Ama bundan sonra olabildiğince Kotlin'de kod yazmaya başlayacağım ve ekibim de günlük programlama dilini Java'dan Kotlin'e çevirecek.Aslında artık Erken Benimseyen değiliz.Lei Juan bir yıldan fazla bir süredir oradaydı. Koltin'i savunmaya devam ettim ve bir uygulama başlattım.Sergey ve AliExpress Rusya ofisindeki diğer öğrenciler de üretimde Kotlin'i kullandılar.Sergey, deneyimlerini birçok yerde kişisel olarak paylaştı.
AliExpress'i Koltin'i benimsemek ve dil seviyesinden verimliliğimizi artırmak için teşvik edeceğiz.
Alibaba kıdemli teknik uzmanı Lei Juan, programcı öğrenimi üzerine son makalesinde çok şey yazdı.Onlara katılıyorum.Özellikle sevmek istediğim sözlerden biri:
Programcılarla programlama geçmişiniz hakkında konuşmayın.Birçok deneyim bugün artık uygulanabilir değil.Bazıları olabilir, ancak diğerlerine tarama maliyeti getirecek ve diğerleri onları taramakla uğraşmayacak. 2-3 yıl boyunca teknolojiye dikkat etmezseniz, temelde programcılardan ve programlamadan izole edilmiş olursunuz. Bu mutlak değildir, ancak yanlış gidemezsiniz.
Lütfen orijinal metne bakın: Programcılar kendi başlarına nasıl öğrenirler? Ali kıdemli teknik uzmanlar bunu yapıyor
Öğrenmeye ve birbirinizi teşvik etmeye devam edin.
FaaS
Hizmet olarak işlev, başka bir yeni Buzz Word? Evet, ama bu Buzz Word'e gerçekten inanıyorum. Sektörde AWS Lambda, Google Cloud Functions, Microsoft Azure Functions ve diğer hizmetler birbiri ardına piyasaya sürüldü. Herkes işini zirveye taşımaya çalışıyor. Bunun nedeni nedir?
Bir bulut servis sağlayıcısıysanız, bu sebep açıktır. Rakibiniz, 2 core 4g'den başlayarak docker instance'ına göre ücretlendirme yapar; çağrı sayısına göre ücretlendirme yapabiliyorsanız saatte 30 kez çalışır. Fiyat farkı büyüklük emirleri olmalıdır ve bu numara ile saniyeler içinde rakibi öldürebilirsiniz.
Yukarıdakiler tamamen donanım maliyetinin bir değerlendirmesidir, ancak bu konuya verimlilik açısından da bakmamız gerekir.
Her şeyden önce, İşlev doğası gereği durumsuz ve yeterince hafif olduğu için teoride ms düzeyinde otomatik ölçeklendirmede bir sorun yoktur.Örneğin, graalvm bu konuda büyük bir potansiyele sahiptir.
MS düzeyinde otomatik ölçeklendirme, yalnızca kaynak kullanımını büyük ölçüde iyileştirmekle kalmaz, aynı zamanda işletim ve bakım verimliliğini de iyileştirir.Geliştirmenin neredeyse artık kapasiteyi dikkate almasına gerek yoktur. Örneğin, Double 11 sırasında, büyük ölçüde sistemin her bir parçasının su seviyesinin öngörülen güvenli hatta olmasını sağlamak için birçok basınç testi yaptık. Gerçek zamanlı genişleme ve daralma elde edilirse, trafik zirve yaptığında genişleme yapılacaktır. Tamam.
Hafif olan nedir?
Günümüzde pek çok mühendis, hafiflik kavramını unutmuş olabilir. Herkes çeşitli izinsiz girişlerdir.Basit bir uygulama yazmak ve jar paketlerini yazmak, genellikle işletme kodunun 1 / 10'undan daha azını oluşturur.
Ne kadar belleğin gereksiz yere boşa harcanabileceğini ve ne kadar başlangıç süresinin gereksiz yere artırılacağını bırakın. Bu müşterinin ve gökyüzünün her yerinde uçmanın en sıkıntılı sonucu, geliştirmenin genellikle çeşitli yükseltmeler gerektirmesi ve yükseltilir yükseltilmez askıda kalması ve kontrol edilmesi uzun zaman almasıdır. Sözde performans başlığı altındaki çeşitli ağır istemciler, hizmet karşıtı odaklıdır; dikkatli tasarıma sahip olmayan çeşitli API'lerin neden olduğu uyumsuz yükseltmeler (ve yükseltme kartları yayınlanmadan şiddetli tanıtım) mühendislik karşıtı etiklerdir.
Mikro hizmetler iyi bir şekilde yapılırsa, çok sayıda hafif arabirim biriktirilmelidir. Bu arabirimleri kullanmak için herhangi bir paylaşım / açık / istemci bağımlılığı oluşturmanıza bile gerek yoktur. HSF genellemesini doğrudan kullanabilirsiniz. Bu tür arabirimler kullanıcılar için uygun değildir. Kod ihlali var.
AliExpress'te Koltin DSL ve HSF genelleme çağrılarına dayalı işlevler yazmaya çalıştık (ve daha önce başlattık). Kullanıcıların iş kodlarını yazmak için yalnızca çok basit bir FaaS SDK'ya güvenmesi gerekiyor. Yukarıda bahsedilen Arşimet hizmet keşfine dayanarak, o Mevcut hizmetler hızlı bir şekilde yeniden kullanılabilir ve iş ihtiyaçlarını karşılamak için bazı toplama ve filtreleme işlemleri gerçekleştirilebilir.Bu, kablosuza yakın işletmelerde çok kullanışlıdır. Elbette bu girişim sadece bir başlangıç, ancak aslında çok fazla iş mantığı olduğunu gördük (AliExpress'te 5/1 ila 1/3) Aslında, verinin kendisine güvenmiyor, Function haline getirilebilir ve biz yapabiliriz Bu işletmelerin, herhangi bir ara yazılım istemcisine güvenmeksizin herhangi bir iş ikinci taraf kitaplıklarına ve hatta Hizmet Ağı gibi teknolojilere güvenmelerine izin verin. Bu işletmelerin sahiplerinin her türlü dağınık yükseltme sorununu önemsemelerine, kapasite sorunlarını önemsemelerine gerek yok ve gerçekten yalnızca kendi iş mantığıyla ilgilenmelerine gerek yok.
Bence FaaS bu olmalı ve ben ve ekibim bunu başarmak için çok çalışıyoruz.
Sonunda yazılan: Alibaba International teknik ekibine katılmak için herkese hoş geldiniz İlgilenen öğrenciler bizimle e-posta yoluyla iletişime geçebilirler: juven.xuxb@alibaba-inc.com.
